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Why is Sims 2 Interesting? 


o Massive amounts of content 
« Animation heavy 
« Sound heavy 
o Massive amounts of people! 
o Graphics: “The users design the levels” 


o Visual game scripting language (Edith) drives 
much of gameplay. 


Long Project 


o Started in late 2000 


o Mostly a small research team (5-20 people) for a 
Sew years 


o In full production for 2+ years 
0 250+ people at the end 
o Slipped! From January ‘04 to September ‘04 


o Extended crunch | 


Stats: Highlights 


o4CDs 

o 11,000 shipped animations 

o 1.1 million lines of code 

o 2,400 UI images 

o 1 GB sound data 

o 8 GB development build footprint 


BSS) 


Sausage Factory: Content 


Animation Object 
Scripters 


Asset Compiler 


Tech. Art Modelling 


Photoshop 


ul, 
Effects, 
Lighting 
Scripts 


Object 
Scripts 


Sausage Factory: Code 


2D Resources 


World DB 


DirectX 
Wrapper 


Areas We'll Look At 


Engineel 


lesign 


Object Scripting 


o Lessons learnt, moving forward 


Stats: Art (*) 


o 11,775 shipped animations 

0 4,500 models, 8,100 textures 

0 50,000 lines of effect scripts: 2000 total effects 
0 57 Movies 

o 3.5GB of source data for Sims, 630 MB for 


objects 


Stats: UI 


o 2,400 UI images 

0 240 UI scripts 

o 942 catalog items 

o 2/1 language string packages 


o 92 cursors 
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Art Staffing 


o About 35 artists at peak 
« 17 Animators (12-14 by ship) 
« 13-14 Modellers 
« 3 Technical Artists 
« 2-3 UI Artists 
« 2-4 Effects Artists 


o Some overlap 


Art Tools () 


o Photoshop, Maya-based from the beginning 


o Brought over all Sims 1 animations, targetting 
new skeleton 


o Used none! 
o MEL front end for material system 


« In general, MEL very useful for adding UI, 
absorbing pipeline logic 


Art Pipeline () 


o Photoshop -> TGA -> Asset Compiler (Go2SCO) 
« added direct PSD support: useful because of layers 

o Maya -> EA3 -> Asset Compiler 

o Artists check in source files to perforce 


« Build machine runs them through pipeline, sends 
error summary to submitter (a few minutes) 


« Also updates animation/models report: web-based 
view of every asset and its stats 


The Skeleton 


0 27 facial targets 
packed into 4 delta 
streams 


o 64 weighted bones 


o 116 bones total, 
including grips and 
other registration 
points 


o Skeleton not locked 


Modelling (*) 


o Lucky enough to have continuity from Sims 1x 


o Sims: maintained single texture sheet approach, 
but composited tops/bottoms together 


o Artists weren't given a poly budget: batch count 
is all 


o Ditto textures(!) 


o Contracted out object LODs: tried to always 
have a single-material LOD 
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Modelling Feedback @ 


o Had Texel Density visualisation mode, for 
identifying “hot” objects where texels were 
wasted 


o Had an animated model/texture map display 


o Could switch between four different shader paths 
in viewer to verify lighting was correct. 


Lighting (™) 


o Art produced original lighting design. Had a 
TDD, and was prototyped. 


o Two dedicated people tuning lighting system via 
script system 


« System evolved according to art, especially early on 
¢ Artificial contrast boosters, emphasis on gradients 


« Downside: a large number of knobs, confusing for 
someone new. 


Level of Detail (*) 


o Static LOD 
o Never formally spec’d 


o All Sims had one LOD (two models total), about 
50% of objects had at least one LOD. 


o Initial overly-ambitious plans left us scrambling 
at the end 


o Dropped dynamic LOD switching due to visual 
glitches 


Sound @’ 


o 143 MP3s 

0 43,000 spx vox samples! 

© 2,600 footsteps alone + 7,500 ambient samples 
o 16,000 unique sound events 

o Fully half our data footprint: 1 GB 


0 35,000 sound resources loaded going into the 


neighbourhood | 
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Design on, 


o Difficult! 
« Need to improve on one of the best games of all time 
« Attract new players 
« Without putting off previous players 

o Diverse audience 


« Past surveys have shown even split between at least 
four different styles of play 


o Aiming for 90+ metacritic rating 
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It Gets Worse ‘Don, 


o Big pressure from EA! Constant demo pressure 
worked against design gelling 


o How much new stuff is enough? 


o The ‘spiralling delay’ trap—longer it takes, better 
it has to be 


o Some of earliest ideas cannibalized for 1x 
expansions, plus people who originated them 


o Changed one of the lead designers in 201 
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New Gameplay 


o Movies 

o Aging! 

o Generations and Genetics! 

o Big Life Moments & Cinematics 
o Aspirations? 

o Wants & Fears?! 


o Done. Phew. 
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Process bn, 


o After slip, needed extremely tight control to 
ensure we hit our mark: 


« Change review—any new design feature thoroughly 
vetted, most dropped 


« Feature producers dedicated to seeing a particular 
feature completed 


« Big new areas were tightly compartmentalized 


« E.g., wants and fears: two engineers working closely 
with OE and design/production 
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It shipped! on, 


o The delay was crucial 


o Finally got enough compelling new gameplay to 
bring back previous buyers. 


o Finished (most of) engineering 
oI million units sold in 10 days 
o Sales in Europe > North America 


o Lesson: Never give up! 
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But at a Cost ‘Don, 


o Constant design change was a negative for the 
rest of the team 


o Most of Maxis moved to EARS in early 2004 
« Corresponding loss of studio identity 

o Various talented people burnt out, some leaving 
« Worry that will impact future hiring prospects 


o Big incentive to learn how to manage “big 
product” process better! 
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Object Engineering @® 


o 18-19 OEs 
o 1,700 game objects! 
o Simulator and object scripts drive all gameplay 


o Mostly nice coupling of logic and associated 
game object 


o Simulator closely coupled with C++ primitives 


o Sometimes mismatch between complexity of C++ 
primitives and simplicity of Edith ESS?) 
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Artist/OE Interaction ss 


o Essentially, artists provided source animation, 
OEs supplied blending (not ideal) 


0 A big problem synchronising 


o Skunkworks project produced “Clockwork”, 
which allowed easy previewing of animations 
and associated effects 


o OEs could use this to explore art assets when 
writing scripts, rather than bugging artists 


Edith ss 


o Less interesting than you think! 
o Actually, visual scripting doesn’t work very well 
« No revision history 
« No good search/replace 
« Single edit: once person at once 
« Difficult for script sweeps 


o At the end of the project, all OEs wanted to move 
away from it 
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Edith ss 


o Positives: having a good debugger is crucial 


o After SC4 and Sims 2, studio consensus is that 
Edith has more cons than pros 


o The future: Lua 
« Used on SC4 with some success 
« In use on various next gen titles 


« But debugger a work in progress 
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Engineering ea, 


o Around 28 engineers at peak. Very roughly: 
« 4 Simulation 
«SUL 
« 4 Graphics only, 7 Graphics/Gameplay/World 
« 4 General 
« 2 Animation 


« 1 Audio 


Stats: Engineering @ 


o 1.1 million non-comment, non-blank lines of code 
« 325,000: framework code shared across the studio 
« 80,000 graphics engine, 45,000 animation 
« 110,000: Shared between app/tools 


+ 540,000: game-specific. Gameplay, UI, world 
construction, lighting... 


o 17,000 lines of material/shader scripts 


o 1,000+ lines camera/catalog/lighting 
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Building Stuff @ 


o Dedicated engineer: The World DB 

¢ Terrain, all house geometry, object location 
o Bridge between gameplay and engine 
o Kept tile-based system 

« Mostly for Ul/gameplay reasons 


« Actual world DB code mostly only cared about walls 
and rooms as quad-edge data structure 


« But this wound up being overly general 
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Routing 


Routing en. 


0 Achilles heel of Sims 1 
« Painful: “Party syndrome” 

o Contracted company to write a replacement 
« But, slow, memory hungry, not that good 
¢ Integral part of gameplay: needs iteration 

o Instead, dedicated an engineer to the system 


o Worked with OEs to solve most problems 
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Routing 


o Standard, quad-tree based 
o Smarts improved, higher tile granularity 
o Tied to simulator: gardener, ghost, fireman 
o “Step over” 
« Essential for all those messes on the floor 
o “Side stepping” 


« Two Sims can pass each other in a narrow sp 
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Animation a 


o Full multi-channel blending, two-bone IK 
o Look at 
« Sims can glance at each other on room entry etc. 
o Hair bounce 
o Standard Reach 
« Used for Sims to hit various targets 


o Cinematics 
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Effects System em. 


o Script-based system 


« Effects composed from “components” : particle 
systems, decals, sounds, models... 


« Hierarchical: can nest effects, “meta” particles 
« Random walks, particle stretch, attractors, colliders 
o Key: all scripts are hot-loaded, rapid iteration 


o Handles UI too: thought balloons, most build 
mode tools 


38 


Example: Fishies ©@ 


o The fish tank is all an effect 


« Fish are model particles with random walks bounded 
by colliders 


« Game can kick an effect between states 


« When fish die, wind force floats them upwards until 
they hit tank’s “top” collider 


« On collision, die and spawn dead fish model 


« Can also switch to state with food attractor 


39 


Neighbourhood ea 


o Lots were imposterized on lot exit 


¢ All walls and floors captured into small set of texture 
pages via render targets 


« Object substitution for “important” objects 
o SimCity tie-in with terrain generation 

« Roads and trees imported directly 

« Everything else is effects 


« User can even place these 
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Lighting System @ 


o Lighting was room based 


« Each room had a light rig generated for it 
automatically 


« User-placed lights only affected objects in that room 
« Portals transmitted light between rooms 
o Time of day states, smooth transitions 


« But, states cut to day/night only. Smooth object light 
transitions killed due to engine issues. 
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Lighting 


Portals 
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Lighting ea 


o Exterior lighting predefined 


o Objects and portals have various light 
multipliers depending on inside/outside 


« Falloff, cutoff, intensity, directionality, etc. 
« Had 2x “over-bright” lighting 
o Floor and walls were light mapped 


« 2D Diffusion algorithm used for “faux” radiosity 
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Shadows eng. 


o Terrain and house: height map shadows 
« Fast CPU-side algorithm 
« Baked directly into light maps 
« Allowed simple object-as-a-whole shadowing 
o “Cookie-cutter” projective shadows 
« Dynamic only for Sims, and some animating objects 


« Static for objects, updated in a staggered manner 
with a frame budget. 


44 


Shadows eng. 


o Tricks 
« Blur and threshold, so could use pretty low-res maps 
« Share for identical objects with same rotation 
« Many shadows packed into a single render target 
o Indoor: GUOBS 
« Prebaked “straight down + ambient” shadows 


« Contact shadows, e.g. for wall objects 
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Scene Graph ea, 


o Graphics engine was a fully general scene graph 


o All model, camera, and hardware light 
manipulations were carried out via graph node 
manipulations 


o A model was just a (tagged) subbranch of the 
scene 


« Could be many nodes: hundreds for a Sim 


« Many operations involved traversing a branc 
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Graphics Performance @ 


o Many objects in a house 


o Terrain and house split into sectors for culling 
and dynamic lighting 


o As batch count hits the thousands, start to get 
CPU hit 


« Generic scene-graph-based graphics engine rebuilt 
display list every frame: CPU hit per part 


« DIP cost becomes prohibitive 
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Solution: Dirty Rects @ 


Dirty Rects eo 


o No, really. (And we thought SC4 was it.) 


o Initial “hold” scheme gradually morphed into an 
SC4-style static/dynamic layer model 


o Cause of some of our card compatibility 
problems. (Copying depth surfaces is tricky) 


o Lighting system required complicated last-minute 
update to generate dirtied areas: tile-based 


o Shadows, particle systems, etc. retrofitte 
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Target Platforms @ 


o Order of magnitude differences between our low 
end and high end in many categories 


« Memory, VRAM, Card capabilities 


o Had to support non-T&L commodity Intel 
hardware 


o Pixomatic fallback for unsupported cards 


o Biggest target was DX7-level cards 


Game Configuration @® 


o Complicated! 


o Used SC4-derived configuration system, but with 
more logic in the scripts 


o Cards are identified from vendor ID, plus driver 
version 


o Special cases as appropriate 


o Usual headache estimating texture memory 


Memory ea 


0 A lot of STL 
« Not always efficient, but golden for leak prevention 

o Ref counting and interfaces: AutoRefCount<> 

o Custom allocators 
« Per-object pools: very low allocate/dealloc overhead 
« A refined cross-platform evolution of dlmalloc 


o Per-class leak detectors 
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Leak Observations en. 


o Ranking leak causes: 
« By far, manual news/deletes 
« Then manual refcounting. 


« Finally, ref-count loops due to improper Init()/ 
Shutdown(). 


o Biggest finalling leak: 
« SC4: Lua! 


« Sims 2: Logging system! 
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Virtual Memory ea, 


o Traditionally the crutch of PC games 


o Free lunch is running out: Virtual Memory 
fragmentation and exhaustion rearing its head 


o DLLs carve off large amounts of address space 
o Operating system takes ever larger amounts 


o Memory fragmentation can bloat application's 
footprint 


Virtual Memory 


Blue: reserved, white: committed, 
green: exe/dll, red: mmap 
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Resource Management en. 


o Key based: originally 96 bit keys 
« Resource UID/Group UID/Instance UID triplet 
o Unpacked form: resource is a file 


o Packed form: package compiler mapped resource 
directory hierarchy into a set of large files 


o Worked weil for previous large-content games 


Problems em. 


o Overused resources. Some simulator resources 
were tiny: 12 bytes each! 


o Models stored as scene graph nodes etc.: a single 
model could easily become 30-50 resources 


o 15,000 models/anims -> 100,000+ resources 


o Key collision: Sims 2 engine allocated resource/ 
group via class UIDs, and hashed string file 
names into instance ID. A hash is not a UID. 


Problems em. 


o What about custom content? 
« Player A loads skins created by players B & C 
« Naming doesn’t work: they both called it “Bob” 


o Large number of files meant the development 
build’s load time became prohibitively slow 


« Load logs were main tool for identifying problem 
areas: simple time-stamped checkpoints. 


« Added development build caches 


58 


Solutions a, 


o In the end, just extended instance ID to 64 bits 


« Case study in making risky changes late in 
development. (Happened after BodyShop ship) 


« Work was done in a sandbox separate from main 
development line, and tested thoroughly before merge 


o For custom content, relied on trusty 128-bit GUID 


¢ Alternative: use hashing, deal with collisions. But 
gets complicated fast. Simple brute force solution is 
preferable. 
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Configuration Management ow 


o Soaked up a lot of effort: 6-8 engineers 
o Testing 
« Drove the game through the command console 


« Tests could then be scripted using a simple command 
script. 285+ test scripts! 


« Highly successful approach, used on a number of 
previous products 


o Simple “sniff” test required before all ch 
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Configuration Management om 


o Adopted “DevTrack” bug database during SC4 
« Awful—slow and buggy, but stuck with it, improved 
¢ Interaction with testers limited to this 
« Testers: hundreds 

o “Robbie” tool for rolling out builds 
« Builds copied incrementally. Could be slow 


« No rollback facility 
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Source Control om 


a fe 
1 4 
Ee e-e 


Testing Testing 


o Two code lines, builds from both were tested 


o Pre-checkin code reviews tried early and 
abandoned. Reinstated during tine. i 
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Lessons Learnt 


What Went Right 


o We could always hit art lock. The explosion in art 
assets required turned out to be the least of our 
scaling problems 


« Learn from the animation industry—they’ve been 
doing this for a while 


« Hire from the animation industry. As content gets 
larger, processes get ever more similar 


Art Lessons 


o Need stable design 
« Too many cooks syndrome 
« Need concept art, templates, established look 


o Modellers <-> animators <-> OEs sit closer 
together 


o More consultation from engineering. Tighter 
turnaround for code changes 


o Lack of technical art types hurt 


Design Risk 


o Well known: cost of a bug increases the later you 
catch it 


oe Corollary: cost of design changes increases 
exponentially the later they occur 


o But Sims 2 couldn’t afford to ship without getting 
the design right 


o Caught between a rock and a hard place, but 
need to avoid this in future. 


Engineering Lessons 


o Concentrate on the game, not the engine 


o Beware of cathedral building: Get systems in 
place early 


o Scene graph belongs in the pipeline 
o Never ignore value of shipping-hardened code 
o Don't contract out core gameplay components 


o More urgency! 


What Went Wrong 


Transporter Accident #231 


Codebase 


o Some areas of the code base were overengineered 


« E.g., pixel formats were represented by a number of 
COM interfaces. 2200+ lines of code in all. 


o Bubble-wrap syndrome 
« Feels like it should be simpler to do ‘xX’ 
o Idea: Prefer toolkit approach to one-stop-shop 


« Too generic = too hard to change and iterate 


Template Metaprogramming 


o Math/Vector library used this 


¢ Unintuitively turned out to be a slight decrease in 
performance in optimized release build 


« Compiler couldn't deal well with deep recursion 
o Issues: 
« Heavy impact on debug speed (75% hit) 
o Vec4 + Vec4 = 16+ function calls 


¢ Difficult to debug: deep stack traces 


API Churn 


o Lock low level parts of the game well before the 
final phase of development! 


o API churn in low level systems has knock-on 
effect 


« Engineers can't keep track of current feature set, or 
propagate knowledge about that feature set 


« Introduction of subtle bugs 


« Can't build on sand 


Productivity 


o One issue: lack of productivity for some core 
tasks 


« Spent weeks or months trying to do some things “the 
right way” 
« Planned overly-ambitious systems, ran out of time to 


implement them 


o But what's wrong with taking time to build a 
clean forward-looking system? 


Opportunity Cost 


o We have nice normal maps. But they only show 
up on a 128MB+ card 


o Static LODs: picked depending on machine type, 
don’t change in the lot 


o Shader path that consumed most dev. time (DX8) 
was dropped in last weeks 


o Hacky game-side culling. (Objects hidden 


manually by world DB code.) f 


Going Forward 


o How are we applying these lessons? 


o Real Estate has location, we have... 
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Preproduction 


o One of the biggest learning experiences of Sims 
2: this is crucial for large projects 


« Explore and solidify design with prototyping 
« Assemble look bibles, concept art, storyboards 
« Explore any new technologies necessary 

o Then, slowly ramp up to full production 


« Must be sure to have all ducks in a row, and only add 
people when underlying systems are ready 


Why not before? 


o Sims 2 was small, “under the radar” research 
team for a few years 


o Flipped directly to production when studio focus 
changed 


o Maxis did not have a lot of experience with 
preproduction concept 


o Deadlines and team sizes hadn't been such that it 
was crucial 


Communication 


o Return of the King used “pod” style of working 
« Small, tightly coupled, interdisciplinary groups 


o Model has worked well at Maxis in an ad hoc 
way, now being adopted more formally 


o Goal is to increase communication bandwidth 
where it matters, 


o Also: flatten hierarchy 


Example: Pools 


Swimming Pools 


o Skunkworks team got together to save them: 
« Simple set of animations 
« Changes to router and world to treat as special room 
« Basic interacting water surface with caustics 


o All put together in only a few weeks outside 
normal tasks 


o Slip allowed more animations and lighting 
refinement 


Art 


o Already implementing pre-production in a 
number of development titles 


« Successfully using concept artist to rapidly explore 
both look and design space 


o Work to have content validation tools working in 
place before production 


o Replicate Sims 2 auto-content-build and content 
browser on other projects 


Engineering 


[_xiss_] 


o It's all about managing complexity 


o Prefer smaller, tighter teams focused on 
particular features 


o Prefer rapid development when the new system is 
an unknown 


Technology 


o Transitioning to toolkit approach to graphics API 
o Switching to text-based scripting 


o Better and more integrated game object/asset 
databases 


o Continue to evolve scripted testing 
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Extras 


o (Aka, slides that got cut) BSS) 


Dirty Rects 


o Two layers: 
« Static (house, terrain) 
« Dynamic (Sims, effects, animating objects) 


o Because of after-the-fact nature, difficult to track 
down all objects that went into wrong layer 


o Two colour, two depth-stencil targets 


o NVIDIA had decent support for copying multi- 
sample surfaces around, ATI not so hot 


Hardware Targets 


oBasic platform approaches 
«Pixomatic - SWVP, Software rasterization 
«Intel UMA - SWVP 
«DX7 - FFVP, sw skinning, hw lighting 
«DX8 - HWVP, sw skinning, VS/PS lighting 


«DX9 - HWVP, hw skinning, VS/PS lighting, 
Sramebuffer effects 


Hardware Headaches 


o Example constraints: 


Pixomatic does not support scissor. 

Pixomatic only supports power of two render target textures. 
Intel does not support post projection per pixel divide. 

Intel has no hwvp. 

Intel has no support for Command Queue flushing event query. 
Nvidia pre GF3 has no occlusion culling 

Nvidia GF4 has no support for clip planes. 

ATI pre 8500 has no occlusion culling 

Older drivers (DX8 level) do not support depth copies. 

ATI can only support a single AA surface on a discardable backbuffer (not testable 
with cap). 

Nvidia has no MRT support until Nvidia 6600, 6800. 

ATI supported MRT with 9500+ series. 

No 16-bit, 32-bit blending support until Nvidia 6600, 6800. No support yet on ATI. 
Shader model 3 only on Nvidia 6600, 6800 parts. 


Hardware Headaches 


o Sometimes speed is more important than features 


« FX series treated as a DX8 part, because it doesn't 
run fast enough for DX9. 


o Control-panel-forced antialiasing is the root of 
all evil* 


o Because of issues with multisample buffers and 
copies on some cards, had several different dirty 
rect paths 


*Well, much of it. 


Technology Sharing 


o Maxis does a pretty good job at this already: has 
central framework 


o Most projects share core platform utility, 
persistence, and UI code. 


o The key so far: no central tech group 
« Usually the death of any shared technology 


« Become detached from “front line”, design by 
committee 


Future Resource Solutions 


o Package IDs 
« Res IDs default to referring to internal resources 
« External references thunk via a package ID table 
o Or go entirely string based. But: 
« Storage hit: memory is getting more precious 


« With large hierarchies, many strings have a common 
prefix: slow string compares. 


« Hierarchy manipulation becomes string glui 


Load Times 


o Long load times hurt *everyone* 
« Engineers, OEs 
« Artists (even viewer was affected) 
« Producers 
« Multiply number of people by time lost per day 


o A measure of how large and slow moving the 
team had become that we didn’t deal with this 
effectively. 


Gameplay is King 


o Shipped lighting doesn't look as good as at 
previous stages in development 


o You have to be able to see to play! 


« Good lighting relies on contrast, but player must be 
able to see all interactable objects well. 


« Player is focused on the Sim 
« Dark rooms artificially brightened 


« 2x lighting actually worked against us here 


Reflections 


o Initially had ‘faked’ floor reflections 
o Neighbourhood water reflection: easy 


o Mirrors: took forever to implement. Majorish 
performance hit. 


o Implementing mirrors consumed enough time 
that ‘faked’ floor reflections were never replaced. 


« Lesson: don’t kill off cheap tricks until the 
replacement is up and running 


Video Recorder 


o Every game should have one 
« Development: bugs, marketing 
« Ship: give your users the chance to show off 


o Frame stepping to keep frame rate constant for 
recording 


o Did YUV conversion and down sampling on the 
card where possible, to get around miserable 
GPU->CPU transfer speeds. 


Learning from Movies 


o In the genre of content-heavy games, we are 
moving in the direction of the animation industry. 


« Large art teams: many animators, modellers, lighters 


+ Lots of past experience in decoupling these into 
departments/groups 


« Much smaller engineering groups, maintaining core 
tools and systems that don’t change much. 


« TDs: scripting, hacking up particular effects 


Learning From Movies 


o But, still differences: 
« Gameplay! 
o But reduced in “track” games 
« Platforms 
o Greater diversity 
o More rapid turnover 


o Greater range in capabilities 


Software Engineering 


o Games are different 


o Challenging technical problems, often without 
prior experience 


o Evolving design 
o Rapid development 


o Iteration is king 
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UI 


o Thanks to a combination of existing system, and 
its nature, easily separable 


o 2-4 Engineers 


o Pretty close contact and iteration with art, and in 
turn with design 


o Pie menus! 


Silly Example: The Plumbob 


o One of the first things 
the Sims 2 team did: 
ditch it for something 
more appealing 


o In the meantime it 
became a marketing 
symbol for Sims 1 


o So, sexed it up, put it 
back 


Tools: Worse is Better 


o Simple manual tool is better than an elaborate, 
well-designed one. 


« 80% chance the well-designed one will never be 
finished 


« Simple one gives you 90% of the info, and shows 
where to look next. 


« You were probably looking for the wrong thing, 
anyway 


Books for Management 


o Mythical Man Month 


« Has more than “adding people to a project makes it 
take longer” 


o Peopleware 
o Facts and Fallacies of Software Engineering 


o Antipatterns 


